System for accepting a first currency for making payment for a transaction and paying for the transaction with funds in a different currency.

ABSTRACT

A method and system for transferring value to a user of a transaction system including receiving from the user a request for value, evaluating the risk involved in providing the value by evaluating information accessible to the transaction system, selectively approving the request for value based on evaluating the risk involved, and distributing the value to the user. The information that is accessible to the transaction system may be stored at the transaction system or separated from the transaction system. The value may include funds, a line of credit, coupons, or gift certificates, and may be distributed over a period of time. The user may be a buyer or a seller.

RELATED APPLICATIONS

The present application is a continuation of U.S. patent applicationSer. No. 13/569,883, filed Aug. 8, 2012, which is a continuation ofprior U.S. patent application Ser. No. 12/397,244, filed Mar. 3, 2009,which claims the benefit of the filing date of U.S. patent applicationSer. No. 11/332,068, filed Jan. 13, 2006, now U.S. Pat. No. 7,899,712,which claims the benefit of U.S. patent application Ser. No. 09/577,434,filed on May 22, 2000, now U.S. Pat. No. 7,449,875, which claims thebenefit of the filing date of U.S. Provisional Patent Application Ser.No. 60/190,420, filed Mar. 17, 2000, the applications of which areincorporated herein by reference in their entirety.

FIELD OF THE INVENTION

The present invention relates generally to the field of e-commerce and,more specifically, to facilitating online payment transactions in anetwork-based transaction facility using multiple payment instructions.

BACKGROUND OF THE INVENTION

For users of a network-based transaction facility, a reliable andconvenient payment mechanism is particularly important for enhancinguser trust in the transaction facility. A typical network-basedtransaction facility, however, does not ensure the expedient and securecompletion of payment transactions. Instead, payment transactionsbetween traders of an online trading community are typically conductedin a conventional, time-consuming manner using paper checks and moneyorders. Accordingly, such payment transactions delay payments to sellersand delivery of purchased goods to buyers. In addition, sellers areexpected to bear the risk of bounced checks and buyers are running therisk of not receiving the goods after sending the money.

The above problems are typically faced by individuals or smallbusinesses who cannot afford to build or buy the infrastructure toaccept credit card payments from buyers in the network-based transactionfacility. However, even a seller who does accept credit card paymentscan still lose those buyers who appreciate the convenience of onlinepayments but do not have access to credit cards. In addition, a buyermay prefer not to disclose his or her credit card information over theInternet in general, or to a certain seller in particular. Further,credit card payments may not always be desirable for sellers because oftheir charge back recourse to buyers.

Therefore, it will be advantageous to provide traders with an efficientand secure mechanism for facilitating online payment transactions via avariety of payment instruments.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example and notlimitation in the figures of the accompanying drawings, in which likereferences indicate similar elements and in which:

FIG. 1 is a block diagram of one embodiment of a system for processingonline payment transactions between participants in a network-basedtransaction facility;

FIG. 2 is a block diagram of one embodiment of a network-basedtransaction facility;

FIG. 3 is a block diagram of one embodiment of an online paymentservice;

FIG. 4 is a block diagram of an exemplary online payment servicesupporting multiple data centers;

FIG. 5 is a flow chart of an exemplary method for facilitating onlinepayment transactions using multiple payment instruments;

FIG. 6 is a block diagram of one embodiment of a database maintained byan online payment service;

FIG. 7 is a block diagram of one embodiment of a process flow forevaluating risks involved in an online payment transaction;

FIG. 8 is a block diagram of one embodiment of an interface sequenceimplemented to facilitate online payment transactions through multiplepayment instruments;

FIG. 9 is a flow chart of an exemplary method for facilitating onlinepayment transactions through multiple payment instruments using riskanalysis;

FIGS. 10-19 are exemplary representations of various interfaces includedin the sequence of interfaces shown in FIG. 8; and

FIG. 20 is a block diagram of one embodiment of a computer system.

DETAILED DESCRIPTION

A method and apparatus for facilitating online payment transactions in anetwork-based transaction facility using various payment instruments aredescribed. In the following description, for purposes of explanation,numerous specific details are set forth in order to provide a thoroughunderstanding of the present invention. It will be evident, however, toone skilled in the art that the present invention may be practicedwithout these specific details.

System for Processing Online Payment Transactions

FIG. 1 is a block diagram of one embodiment of a system for processingonline payment transactions between participants in a network-basedtransaction facility. In this embodiment, a client 100 is coupled to atransaction facility 130 via a communications network, including a widearea network 110 such as, for example, the Internet. Other examples ofnetworks that the client may utilize to access the transaction facility130 include a local area network (LAN), a wireless network (e.g., acellular network), or the Plain Old Telephone Service (POTS) network.

The client 100 represents a device that allows a user to participate ina transaction facility 130. The transaction facility 130 handles alltransactions between various participants including the user of theclient computer 100. In one embodiment, the transaction facility 130 maybe an online auction facility represented by an auction web site visitedby various participants including the user of the client computer 100.An exemplary auction facility is described in greater detail inconjunction with FIG. 2. Alternatively, the transaction facility 130 maybe an online retailer or wholesaler facility represented by a retaileror wholesaler web site visited by various buyers including the user ofthe client computer 100. In yet other embodiments, the transactionsfacility 130 may be any other online environment used by a participantto conduct business transactions.

The transaction facility 130 is coupled to an online payment service120. In one embodiment, the transaction facility 130 is coupled to theonline payment service 120 via a communications network such as, forexample, an internal network, the wide area network 110, a wirelessnetwork (e.g., a cellular network), or the Plain Old Telephone Service(POTS) network. Alternatively, the online payment service 120 isintegrated with the transaction facility 130 and it is a part of thetransaction facility 130. The online payment service 120 is also coupledto the client 100 via any of the described above communicationsnetworks. The online payment service 120 is a service for enablingonline payment transactions between participants of the transactionfacility 130, including the user of the client computer 100.

In one embodiment, the online payments service 120 enables theparticipants to make online payments in the course of business conductedin the transaction facility 130 using multiple payment instructions.These payment instructions may include, for example, credit cards, debitcards, wire transfers, electronic funds transfers (EFT), transfers frominternal accounts within the transaction facility 130 or the onlinepayment service 120, loan financing, lines of credit, coupon or giftcertificates, etc. In this embodiment, the transaction facility 130facilitates business transaction between the user of the client 110 andother participants. The client t110 presents user interface informationto the user. The user interface information identifies multiple paymentinstruments available for processing payment transactions pertaining tocorresponding business transactions.

In one embodiment, the user selects one or more payments instrumentsfrom the available payments instruments. The client 110 thencommunicates payment option information of the user to the transactionfacility 130. The payment option information indicates the willingnessof the user to accept payments from other participants via the selectedpayment instruments. The online payment service 120 receives the paymentoption information from the transaction facility 130, communicates thepayment option information to a participant conducting business with theuser, and enables the participant to choose a preferred instrument fromthe payment instruments selected by the user. The online payment service120 then accepts personal billing information concerning the preferredpayment instrument from the participant to facilitate the paymenttransaction between the participant and the user.

Transaction Facility

FIG. 2 is a block diagram illustrating an exemplary network-basedtransaction facility in the form of an Internet-based auction facility200. While an exemplary embodiment of the present invention is describedwithin the context of an auction facility, it will be appreciated bythose skilled in the art that the invention will find application inmany different types of computer-based, and network-based, commercefacilities.

The auction facility 200 includes one or more of a number of types offront-end servers, namely page servers 212 that deliver web pages (e.g.,markup language documents), picture servers 214 that dynamically deliverimages to be displayed within Web pages, listing servers 216, CGIservers 218 that provide an intelligent interface to the back-end offacility 210, and search servers 220 that handle search requests to thefacility 10. E-mail servers 221 provide, inter alia, automated e-mailcommunications to users of the facility 200.

The back-end servers include a database engine server 222, a searchindex server 224 and a credit card database server 226, each of whichmaintains and facilitates access to a respective database.

The Internet-based auction facility 200 may be accessed by a clientprogram, such as a browser (e.g., the Internet Explorer distributed byMicrosoft Corp. of Redmond, Wash.) that executes on the client computer100 and accesses the facility 200 via the communications network 110.

Online Payment Service

FIG. 3 is a block diagram of one embodiment of an online payment service120. The online payment service 120 includes a firewall 300, one or moreweb servers 310, a firewall 315, a set of application servers 320, andone or more databases 330. The firewall 300 isolates the online paymentservice 120 from external Internet accesses. The firewall 310 enhancessecurity within the online payment service 120 by preventing internalaccess to information stored in the database 330. The only accesspermitted to the database is from applications servers 320, making validdatabase requests.

The web servers 310 facilitate the exchange of information between theonline payment service 120, the transaction facility 130 and theparticipants of the transaction facility 130, including the user of theclient 100. In one embodiment, the web servers 310 encrypt data outgoingfrom the online payment service 120 using a secure protocol (e.g., asecure socket layer (SSL) protocol, a secure HTTP protocol, etc.). Inone embodiment, a digital signature mechanism is implemented to preventtampering of data prior to the encryption stage.

The application servers 320 handle various tasks executed within theonline payment service 120. Each application server 320 is responsiblefor a certain pre-assigned task. These tasks may include, for example,executing payment transactions, registering participant accounts,maintaining account statuses for each user, providing customer service,delivering emails, providing analysis (e.g., risk analysis) andreporting, processing electronic fund transfers EFTs, and otherapplication services. The applications servers 320 access the database330 to enter or retrieve various data. The database 330 is described ingreater detail below in conjunction with FIG. 6.

In one embodiment, the online payment service 120 is coupled, via anetwork, to multiple external payment processors to complete varioustypes of online payment transactions. For example, the online paymentservice 120 may be coupled to a credit card processor to process creditcard payments. The online payment service is 120 may also by coupled toan EFT processor to process electronic checks and money order payments.Other external payment processor may include, for example, a wiretransfer processor, a loan financing processor, a line of creditprocessor, a coupon or gift certificate processor, etc.

FIG. 6 is a database diagram illustrating an exemplary database 600supported by the online payment service 120. The database 600 may, inone embodiment, be implemented as a relational database, and includes anumber of tables having entries, or records, that are linked by indicesand keys. In an alternative embodiment, the database 600 may beimplemented as collection of objects in an object-oriented database.

Central to the database 600 is a user table 610, which contains a recordfor each user of the online payment service 120. A user may operate as aseller, buyer, or both, within the transaction facility 130. A sellertable 620 is linked to the user table 610 and includes more detailedinformation about each seller. A buyer table 630 which is also linked tothe user table 410 includes detailed information about each buyer. Thedatabase 600 also includes payment instruments tables 670 that may belinked to the user table 610. Each payment instrument table 670 pertainsto an individual payment instrument available for use in the transactionfacility 130. Available payment instruments may include, for example,credit cards, debit cards, automated clearing house (ACH) transfersusing electronic checks and money orders, wire transfers, transfers froman internal account within the online payment service 120 or thetransaction facility 130, loan financing, lines of credit, coupons orgift certificates, etc. Each payment instrument table 670 includescorresponding billing information provided by a user. A user record inthe user table 610 may be linked to a payment instrument record inmultiple payment instrument tables 670 if the user provides billinginformation on more than one payment instrument.

The database 600 also includes a payment transaction table 640 which islinked to the seller table 620 and the buyer table 630. The paymenttransaction table 640 contains information on each financial exchangebetween a buyer and a seller. A payment transaction in the transactiontable 640 may be represented by one or more accounting records in anaccounting record table 650. The accounting records support anaccounting system of the online payment service 120 and contain variousaccounting information, such as, for example, information on debits andcredits to buyers, sellers, the online payment service, or other thirdparties participating in payment transaction. A payment transaction thatdoes not correspond to any accounting record may indicate that thetransaction was not completed successfully (e.g., the buyer's creditcard was invalid).

A ledger table 660 is linked to the accounting record table 650, theuser table 610 and the payment instrument tables 670. A ledger recordcontains information on an actual fund transfer between a user and theonline payment service 120. The funds transfer may be a debit (e.g., acharge to a buyer's credit card) or a credit (e.g., a disbursement to aseller's checking account). The funds transfer is conducted through aparticular payment instrument selected by the buyer and seller andapproved by the online payment service 120 in a manner described in moredetail below.

One embodiment of an architecture of the online payment service 120 willnow be described in more detail. In this embodiment, the online paymentservice 120 supports a large number of buyers and sellers who aredistributed across the globe, executing transactions at any time of dayand night. In order to provide stable physical environment and reliableapplication architecture, online payment service clusters are installedat several different geographical locations. If a single data centerlocation goes down, transaction volume can be processed by clusters atthe remaining locations. Each cluster, in turn, may consist of multiplemachines with redundant service.

FIG. 4 is a block diagram of an exemplary online payment service 120supporting multiple data centers. In this embodiment, clusters 400, 410and 420 reside in different data centers. The same web servers 310 andapplication servers 320 are included in both clusters 400 and 410. Theapplication servers 320 of the clusters 400 and 410 perform transactionmanagement functions, such as, for example, transaction execution,account registration, account status, customer service, e-mail delivery,etc. In one embodiment, in each of the clusters 400 and 410, multipleinstances of every application server run in parallel to balance thesystem load between the different functions. Application servers can beinstalled on different physical machines to increase reliability of thesystem. In one embodiment, each of the clusters 400 and 410 has externalconnections with one or more payment processors (e.g., a credit cardprocessor, an EFT processor, a wire transfer processor, etc).

In one embodiment, each of the clusters 400 and 410 includes aproduction database 330. Shared data (e.g., buyer and seller profileinformation) in the production database 330 may be dynamicallyreplicated to both data centers. Transaction data (e.g., current accountstatement information) may not need to be replicated as it can beconstructed in a variety of other ways using the production data. Forexample, upon a user request for an online account statement, a query(e.g., an SQL query) may be run to build a complete transaction record.

In one embodiment, analysis and reporting functions may be separatedfrom the transaction activity because these functions are timeconsuming. That is, analysis and reporting functions may be executed bythe warehouse cluster 420 located separately from the clusters 400 and410. The analysis and reporting functions may include, for example, riskor fraud analysis, standard reporting, online analytical processing(OLAP) providing database indexing to enhance quick access to data EFTprocessing, etc. The analysis and reporting functions may be carried outagainst a separate data warehouse system, such as a data warehouse 450.Data pertaining to the analysis and reporting may be extracted from theproduction database 330 at predefined time intervals and stored in thedata warehouse 450. As a result, user transaction activity is notimpacted by execution of time-consuming analysis and reportingfunctions.

Multiple Payment Instruments

In order to provide participants of the transaction facility 130 with aneffective and secure mechanism of conducting online paymenttransactions, one embodiment of the present invention proposes a methodand system whereby the participants may conveniently use multiplepayment instruments to make online payments for products obtained in thecourse of their commercial activity in the transaction facility 130.

FIG. 5 is a flow chart illustrating an exemplary method 500 offacilitating online payment transactions using multiple paymentinstruments. The method 500 may be performed by processing logic, whichmay comprise hardware, software, or a combination of both. Theprocessing logic may be either in the online payment service 120, orpartially or entirely in a separate device and/or system(s).

Referring to FIG. 5, the method 500 begins with the online paymentservice 120 communicating user interface information to a firstparticipant via a communications network (processing block 506). Theuser interface information identifies multiple payment instrumentsavailable for processing payment transactions in the transactionfacility 130.

At processing block 508, processing logic in the online payment service120 receives payment option information from the first participant viathe communications network. The payment option information indicates awillingness of the first participant to accept payments from a secondparticipant through one or more available payment instruments. Asdescribed above, available payment instruments may include, for example,credit cards, debit cards, wire transfers, electronic checks and moneyorders. In addition, the online payment service 120 may permit paymentsthrough direct transfers from an internal account which is maintainedfor a participant within the transaction facility 130 or the onlinepayment service 120.

In one embodiment, payment instruments may also include loan financingand lines of credit. In this embodiment, the online payment service 120may cooperate with a third party processor (e.g., a financialinstitution) to process loan financing and to create or extend a line ofcredit for a participant. Other payment instruments may include couponsand gift certificates, or any other U.S. or international vehicles. Inthe cases of coupons and gift certificates, the online payment service120 (in cooperation with a third party or internally) determines whethera coupon or a gift certificate is valid.

Next, processing logic in the online payment service 120 passes thepayment option information to the second participant via thecommunications network (processing block 510). Afterwards, at processingblock 512, processing logic in the online payment service acceptspersonal billing information of the second participant to facilitate apayment transaction between the first participant and the secondparticipant. The personal billing information transferred over thecommunications network pertains to a payment instrument selected by thesecond participant from the payment instruments specified by the firstparticipant.

In one embodiment, processing logic in the online payment system 120communicates the personal billing information of the second participant,via the communications network, to a financial institution to processthe payment transaction. Alternatively, the personal billing informationmay be processed internally (e.g., when a payment is made using a directtransfer from an internal account within the online payment system 120or the transaction facility 130). Afterwards, when the paymenttransaction completes, the first participant is notified. In oneembodiment, notification may be sent immediately after accepting thepersonal billing information (e.g., when a payment is made using acredit card). Alternatively, notification is sent after a certain timeperiod expires (e.g., when a payment is made using an electronic check).

In one embodiment, at various stages of the payment transaction betweenthe first participant and the second participant, risk involved in thepayment transactions is evaluated by a risk analysis system of theonline payment system 120. The various stages may include, for example,the time the payment transaction is initiated, the time either the firstor second participant registers with the online payment service 120, thetime the first participant provides invoice information, the time thesecond participant provides personal billing information pertaining to aparticular payment instrument, the time funds are disbursed to the firstparticipant, etc. Based on the involved risk, the payment transactionbetween the first and second participants may be interrupted orrestricted (e.g., preventing a participant from accepting or paying witha certain payment instrument). The risk analysis system is described ingreater detail below in conjunction with FIG. 7.

In one embodiment, processing logic in the online payment service 120accepts multiple payments owed to the first participants by otherparticipants in the course of business transactions conducted by thefirst participant in the transaction facility 130. The multiple paymentsare accepted via the communications network and may be made usingvarious payment instruments. Next, processing logic in the onlinepayment service 120 accumulates these payments over a period of time andthen distributes a single disbursement which includes the accumulatedpayments to the first participant.

In one embodiment, the online payment service 120 accepts a payment fromthe second participant in one currency and distributes the payment tothe first participant in different currency. The above online paymentoptions address time-consuming and unreliable paper-based paymentmethods and provide an efficient and secure mechanism to conduct paymenttransactions within the transaction facility 130.

FIG. 7 is a block diagram of one embodiment of a process flow forevaluating risks involved in an online payment transaction. As describedabove, the involved risks are evaluated at various stages of the paymenttransaction. The involved risks may concern, for example, a buyer'sability to pay, a likelihood that a buyer or a seller may be fraudulent(e.g., a buyer uses a stolen credit card, or a seller lists goods forsale online with no intent or ability to deliver the purchased goods), aseller's ability to fulfill purchase orders promptly, etc. Based on therisk evaluation, the online payment service 120 may reject or restrict apayment transaction between a buyer and a seller in a manner describedbelow. In one embodiment, the risk evaluation is performed in real timeand enables an uninterrupted processing of the payment transaction.

In one embodiment, the online payment service 120 contains a paymentprocessing system 710 and a risk management system 720. The paymentprocessing system 710 is responsible for executing payment transactions.Specifically, the payment processing system 710 receives informationfrom the transaction facility, stores some or all of this informationfor historical purposes in a local database (i.e., a payment transactiondata store 730), and determines what information to pass to the riskmanagement system 720. The risk management system 720 utilizes thisinformation to determine a risk level involved in the paymenttransaction. In one embodiment, the risk management system 720 may alsouse input from one or more third party risk analysis providers 740 toevaluate the risk level of the payment transaction. The results of theevaluation are passed back to the payment processing system 710 whichcontinues processing the payment transaction based on the evaluationresults.

In one embodiment, payment transactions are initiated in the transactionfacility 130. The transaction facility 130 passes a variety ofinformation concerning a payment transaction and its participants (abuyer and a seller) to the payment processing system 710. The paymenttransaction information may include, for example, a payment transactionamount, currency in which the payment transaction is to be conducted,description of the goods or services being exchanged, etc. Theparticipant information may include, for example, identifyinginformation of both a buyer and a seller (e.g., names, identificationcodes, contact information) and information pertaining to their businessparticipation in the transaction facility 130. For instance, thetransaction facility 130 may pass to the payment processing system 710information on how long both the buyer and the seller have beenregistered with the transaction facility 130, their historical businessactivity within the transaction facility 130 (e.g., number of priortransactions, gross sales, average amount of a sale), userclassification schemes and peer rating schemes used in the transactionfacility 130 (e.g. user feedback ratings), third party trust ratingscarried out by the transaction facility 130 (e.g. credit reports), etc.It should be noted that a wide variety of information other than theinformation described above may be passed to the payment processingsystem 710 from the transaction facility 130 for evaluating potentialrisk involved in the payment transaction.

In another embodiment, the payment processing system 710 itself mayinitiate a payment transaction (e.g., if the payment processing system710 is notified that a buyer and a seller agreed that a payment wouldtake place on a future date). In this embodiment, the payment processingsystem 710 then requests relevant information (including any or all ofthe above information) from the transaction facility 130.

The payment processing system 710 passes any or all of the aboveinformation to the risk management system 720. In addition, the paymentprocessing system 710 may pass certain internal transaction data (e.g.,response codes from a credit card processor) to the risk managementsystem 720. The risk management system 720 uses the above information todetermine the risk level of the payment transaction. In addition, therisk management system 720 may include in its analysis data stored inthe payment transaction data store 730 (e.g. historical transactionactivity of the seller and the buyer) and information collected bysystem operation staff related to either the buyer or the seller (e.g.,customer service responses, “blacklists” identifying fraudulentcustomers, etc.).

In one embodiment, the risk management system 720 also includes in itsanalysis external risk analysis results. In this embodiment, the riskmanagement system 720 may request one or more third party risk analysisproviders 740 to provide an additional evaluation of the risk involvedin the payment transaction. For instance, a financial institution mayprovide additional levels of screening to identify potentiallyfraudulent participants. The risk management system 720 may transmit tothe third party risk analysis providers 740 any or all of theinformation collected for the payment transaction. The third party riskanalysis providers 740 analyze this information and information obtainedfrom their own sources to determine a risk assessment for the paymenttransaction. The risk assessment information is then sent back to therisk management system 720.

Based on the information received from various external and internalsources, the risk management system 720 determines the risk level of thepayment transaction using a scoring algorithm. It should be noted thatany scoring algorithm known in the art may be used by the riskmanagement system 720 without loss of generality. The risk managementsystem 720 produces a consolidated risk response and passes it to thepayment processing system 710. The risk response may include, forexample, information indicating that service should be denied to aparticipant due to high likelihood of fraud, information on arecommended service fee for processing the payment transaction,information on recommended restrictions on payment instruments to beused by either the buyer or the seller, information on recommendedrestrictions on disbursing funds to the seller, etc.

The payment processing system 710 receives the risk response from therisk management system 720 and makes a final determination concerningthe payment transaction. That is, the payment processing system 710 mayreject the payment transaction (or deny service to either the buyer orthe seller entirely), process the payment transaction without anychanges, or restrict the timing and/or the manner in which the paymenttransaction is conducted. For example, the payment processing system 710may limit payment instruments offered for use in the paymenttransaction, may assign or modify a fee for processing the paymenttransaction, may restrict the time or the manner in which funds aredisbursed to the seller, etc.

User Interfaces

Functions of the online payment service 120 pertaining to paymentsthrough multiple payment instruments will now be described within thecontext of user interfaces, according to one embodiment of the presentinvention. FIG. 8 shows an interface sequence 800, according to anexemplary embodiment of the present invention, that may be implementedby the transaction facility 130 and the online payment service 120 forthe purposes of providing multiple online payment options toparticipants in the transaction facility 130. Exemplary representationsof the various interfaces included within the sequence 800 are shown inFIGS. 10-19. While exemplary interfaces are described within the contextof an auction facility, it will be appreciated by those skilled in theart that they may be implemented in many different types ofcomputer-based, and network-based, transaction facilities.

The interface sequence 800 commences with a seller registrationinterface 802 through which a seller may specify what online paymentinstruments the seller will accept from various buyers. The sellerregistration interface 802 is generated by the transaction facility 130and may be accessed at any time during a business transaction (e.g.,during an auction) or upon an end of the business transaction (e.g.,upon en and of auction). The seller needs to go through the sellerregistration interface 802 only once unless the seller wants to modifythe payment instruments specified initially.

Upon the end of the business transaction, an end of business transactioninterface 804 is displayed by the transaction facility 130. The end ofbusiness transaction interface 804 identifies a seller and a buyer andthe payment instruments acceptable to the seller. If the paymenttransaction is initiated by the seller, the seller is then presentedwith a seller login interface 806 which allows the seller to login tothe online payment service 120 by entering the seller's password.Subsequently, the seller is presented with an invoice form interface808. The invoice form interface 808 displays an explanation of thepayment process and requests the seller to enter the invoice terms.

After the seller confirms that the invoice terms are correct, the buyerreceives an email with a link to a buyer login interface 810.Alternatively, if the payment transaction is initiated by the buyer, theinvoice is not generated and the buyer does not need to wait for theabove email. Instead the buyer can directly access the buyer logininterface 810 which enables the buyer to login to the online paymentservice 120.

Next, the buyer is presented with a payment option interface 812 whichallows the buyer to select a particular payment instrument for use inthis payment transaction. In addition, the payment option interface 812enables the buyer to avoid entering the buyer's personal billinginformation in a personal billing information interface 814 if the buyerhas previously registered with the online payment service 120. If so,the buyer is presented with a revision of billing and shippinginformation interface 813 and then with an order placing interface 818.By clicking a place order button on the order placing interface 818, thebuyer authorizes the online payment service to execute the paymenttransaction (e.g., charging the buyer's credit card, initiating anelectronic funds transfer, etc.). Further, the buyer is presented with aconfirmation interface 820 confirming that the buyer's purchase iscomplete. In case of an electronic funds transfer, the confirmationinterface 820 notifies the buyer that the online payment service 120 hasinitiated the buyer's electronic check payment.

If the buyer has not previously registered with the online paymentservice 120, the buyer is presented with the personal billinginformation interface 814 which requests the buyer to enter billinginformation pertaining to the payment instrument selected by the buyer.Next, the buyer is presented with a shipping information interface 816which requests the buyer to enter shipping information for this orderand then with an order placing interface 818 and then with theconfirmation interface 820. Afterwards, the buyer is invited to registerwith the online payment service 120 using a buyer registration interface822. By registering, the buyer permits the online payment service 120 tostore the buyer's personal billing information so that the buyer doesnot need to enter it every time the buyer pays for the goods through acorresponding payment instrument. The personal billing information ofthe buyer is kept confidential and is not communicated to the seller.

The interfaces 802-820 will now be described within the context of amethod 900, according to one embodiment of the present invention, offacilitating payment transactions through multiple payment instrumentsusing risk analysis. The method 900 is illustrated by the flow chartindicated in FIG. 9. The method 900 is performed by processing logic,which may comprise hardware, software, or a combination of both. Theprocessing logic may be either in the online payment service 120, orpartially or entirely in a separate device and/or system(s).

The method 900 commences with providing the seller registrationinterface 802 to the seller at block 904. The seller registrationinterface presents to the seller available payment instruments that canbe used for conducting payment transactions in the transaction facility130.

At block 906, processing logic in the online payment service 120receives information on payment instruments selected by the seller fromthe list of available payment instruments. At block 908, processinglogic in the online payment option 120 determines whether the seller isqualified to use the payment instruments selected by the seller. Thisdetermination is performed using the risk management system 720 asdescribed above in conjunction with FIG. 7.

The method 900 continues with providing the end of business transactioninterface 804 which specifies those payment instruments selected by theseller that were approved during the risk analysis process (block 910).Next, at decision box 912, a determination is made as to whether aninitiator of the payment transaction is the seller or the buyer. If theseller initiates the payment transaction, the seller is provided withthe seller login interface 806 to enable the seller to login to theonline payment service (block 914). At block 916, the seller ispresented with the invoice form interface 916.

Next, at block 918, processing logic in the online payment service 120receives invoice information entered by the seller through the invoiceform interface 808 and then, at block 920, determines whether the selleris qualified to submit the payment transaction described by the invoiceinformation. That is, the risk management system 720 is used to evaluatea likelihood of the seller's ability to fulfill the purchase accordingto the invoice terms. If processing logic in the online payment service120 determines that the seller is qualified to submit this paymenttransaction, the buyer is sent an e-mail which contains a link to beginpayment. The link enables the buyer to access the buyer login interface810 (block 922).

Alternatively, if the initiator of the payment transaction is the buyer,the method 900 proceeds directly to block 922, at which the buyer ispresented with the buyer login interface 810. The buyer login interface810 includes information instructing the buyer to notify the seller(e.g., by e-mail using included e-mail template) about the buyer'swillingness to conduct the payment transaction through one of theavailable payment instruments.

Further, after the buyer successfully logs in to the online paymentservice 120, at decision box 924, a determination is made as to whetherthe buyer is registered with the online payment service 120. If thebuyer is not registered, the buyer is requested to specify a preferredpayment method for this payment transaction through the payment optioninterface 810. If the buyer initiated the payment transaction, thepreferred payment method may be selected from multiple paymentinstruments available for conducting payment transactions in thetransaction facility 130. Alternatively, if the initiator of the paymenttransaction was the seller, the preferred payment method may be selectedfrom the payment instruments approved in the qualification processdescribed above.

At decision box 928, a determination is made as whether the buyer isqualified to use the preferred payment instrument using the riskevaluation process described above. If the buyer is not qualified to usethis payment instrument, the method 900 returns to block 926, at whichthe buyer is asked to select another payment instrument. Alternatively,if the buyer is qualified, at block 930, the buyer's personal billinginformation pertaining to the preferred billing instrument is receivedfrom the buyer through the personal billing information interface 814.Information included in the personal billing information interface 814varies depending on the payment instrument selected by the buyer. Inaddition, the buyer may be requested to enter the buyer's shippinginformation through the shipping information interface 816.

Next, at block 934, processing logic in the online payment service 120processes the buyer's payment and generates the confirmation interface820 notifying the buyer either that the purchase is complete (e.g., thepayment is made through a credit card) or that the buyer's payment hasbeen initiated (e.g., the payment is made through an electronic fundstransfer). Further, the buyer is presented with the buyer registrationinterface 822 which enables the buyer to store the buyer's personalbilling information and shipping information in an account maintainedfor the buyer by the online payment service 120. The method 900 thenproceeds to block 936.

In an alternate embodiment, in which the buyer is already registeredwith the online payment service 120, the method 900 proceeds to block927, at which the buyer is invited to revise his or her billing and/orshipping information through the revision of billing and shippinginformation interface 813. Then, the method 900 proceeds to block 934and further to block 934.

At block 934, processing logic in the online payment service 120disburses funds to the seller. In one embodiment, multiple payments madeby various buyers using the same or different payment instruments areaccumulated on behalf of the seller over a certain period of time andthen a single disbursement (in the amount equal to the accumulatedpayments minus an appropriate service fee) is distributed to the seller.In one embodiment, the time of disbursement, the manner of disbursement(e.g., a payment instrument to be used for disbursement) and the amountof the service fee are determined based on the risk evaluation processdescribed above in conjunction with FIG. 7.

Exemplary user interfaces will now be further described with referenceto FIGS. 10-19. While the exemplary interfaces are described ascomprising markup language documents displayed by a browser, it will beappreciated that the described interfaces could comprise user interfacespresented by any Windows® client application or stand-alone application,and need not necessarily comprise markup language documents. Inaddition, it will be appreciated by those skilled in the art that,although the exemplary interfaces are described in the context of anauction facility, they may be implemented in a wide variety of differenttypes of computer-based, and network-based, transaction facilities.

FIG. 10 illustrates an exemplary seller registration interface 802 thatenables the seller to specify various options concerning businesstransactions that are conducted in the environment of the transactionfacility 130. Some of the various options pertain to payment options,such as payment methods 1010 and online payments 1020. The onlinepayments 1020 specify multiple payment instruments. Although FIG. 10illustrates only credit card and electronic check payment instruments,the seller registration interface may identify a wide variety of otherpayment instruments as described above. Using one or more check boxescorresponding to the payment instruments (e.g. check box 1022 and 1024),the seller may specify what payment instruments he or she will accept inpayment transactions with various buyers.

FIG. 11 illustrates an exemplary end of business transaction interface804 which in this example indicates the end of auction. The end ofbusiness transaction interface specifies payment instruments selected bythe seller (e.g. a credit card 1110 and an electronic check 1120) andenables either the seller or the buyer to initiate the paymenttransaction by using a corresponding link (i.e., a seller link 1124 or abuyer link 1124).

FIG. 12 is an exemplary seller login interface 806 which enables theseller to login to the online payment service 120 by providing theseller's password 1230. The seller login interface 806 also includeslinks to explanations on how to use online payments (e.g., a link 1210to an explanation for a first step of sending an invoice and a link 1220to an explanation for a second step of shipping an item).

FIG. 13 is an exemplary invoice form interface 808 which includes inputfields for entering various invoice information (e.g., a final auctionprice 1330, shipping insurance 1340, sales tax 1350, a message 1386, anda return policy 1388). The invoice interface also specifies paymentinstruments 1380 that are acceptable for this transaction (e.g., creditcard 1382 and electronic check 1384) and provides information on how thepayment transaction will be processed. For example, if the buyer choosesto pay with a credit card, the seller will be notified that the paymentis processed once the buyer's credit card information is received. Ifthe buyer pays with an electronic check, the seller will be notifiedabout the completion of the payment transaction after the expiration ofa certain time period (e.g. in 3-5 days).

FIG. 14 is an exemplary buyer login interface 810 which enables thebuyer to login to the online payment service 120 by providing thebuyer's user identifier 1414 and password 1416. In addition, the buyerlogin interface 810 includes information indicating that the paymenttransaction must be either initiated by the seller 230 (text 1410) orthe buyer (text 1412).

FIG. 15 is an exemplary payment option interface 812 which includesinvoice information 1510 and asks the buyer to select one of the onlinepayment methods (e.g., a credit card 1530 or an electronic check 1540)by using either a “pay with credit card” button 1550 or a “pay withelectronic check” button 1560. The payment option interface also allowsthe buyer to pay in one step using a link 1520 if the buyer isregistered with the online payment service 120.

FIG. 16 is an exemplary billing information interface 814 generated inresponse to a buyer request to pay with a credit card paymentinstrument. The interface 814 includes input fields 1620 pertaining tothe buyer's credit card information. In addition, the interface 814includes information indicating that the buyer's billing information iskept confidential and will not be disclosed to the seller.

FIG. 17 is an exemplary billing information interface 814 generated inresponse to a buyer request to pay with an electronic check paymentinstrument. The interface 814 includes the buyer's checking accountinformation including a bank name 1710, a bank routing number 1720, achecking account 1730, and a buyer's name and a checking account address1750. In one embodiment, in order to prevent potential fraudulentactivity, the interface 814 includes secondary form of identificationinput fields 1762-1768.

FIG. 18 is an exemplary buyer registration interface 822 including inputfields 1810-1850 enabling the buyer to register with the online paymentservice 120 for storing his or her billing information in an accountmaintained by the online payment service 120.

FIG. 19 is an exemplary confirmation interface 820 notifying the userthat the payment transaction has been initiated.

In summary, it will be appreciated that the above described interfaces,and underlying technologies, provide a convenient vehicle forfacilitating payment transactions in a transaction facility usingmultiple payment instruments.

FIG. 20 shows a diagrammatic representation of machine in the exemplaryform of a computer system 2000 within which a set of instructions, forcausing the machine to perform any one of the methodologies discussedabove, may be executed. In alternative embodiments, the machine maycomprise a network router, a network switch, a network bridge, PersonalDigital Assistant (PDA), a cellular telephone, a web appliance or anymachine capable of executing a sequence of instructions that specifyactions to be taken by that machine.

The computer system 2000 includes a processor 2002, a main memory 2004and a static memory 2006, which communicate with each other via a bus2008. The computer system 2000 may further include a video display unit2010 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)).The computer system 2000 also includes an alpha-numeric input device2012 (e.g., a keyboard), a cursor control device 2014 (e.g., a mouse), adisk drive unit 2016, a signal generation device 2020 (e.g., a speaker)and a network interface device 2022.

The disk drive unit 2016 includes a computer-readable medium 2024 onwhich is stored a set of instructions (i.e., software) 2026 embodyingany one, or all, of the methodologies described above. The software 2026is also shown to reside, completely or at least partially, within themain memory 2004 and/or within the processor 2002. The software 2026 mayfurther be transmitted or received via the network interface device2022. For the purposes of this specification, the term“computer-readable medium” shall be taken to include any medium that iscapable of storing or encoding a sequence of instructions for executionby the computer and that cause the computer to perform any one of themethodologies of the present invention. The term “computer-readablemedium” shall accordingly be taken to included, but not be limited to,solid-state memories, optical and magnetic disks, and carrier wavesignals.

Thus, a method and apparatus for facilitating online paymenttransactions in a network-based transaction facility using multiplepayment instruments have been described. Although the present inventionhas been described with reference to specific exemplary embodiments, itwill be evident that various modifications and changes may be made tothese embodiments without departing from the broader spirit and scope ofthe invention. Accordingly, the specification and drawings are to beregarded in an illustrative rather than a restrictive sense.

1. (canceled)
 2. A system comprising: at least one hardware processormaintained to communicate with a client machine via a network interface,the at least one hardware processor configured to include: a receivermodule to receive, via a message exchange with the client machine,information that identifies a first account for making a payment for atransaction in a first currency, the information being generated byselection of a selectable element at a user interface at the clientmachine, the message exchange utilizing the network interface of the atleast one hardware processor; a retriever module to retrieve informationrelated to the first account; an approval module, responsive to riskanalysis of the information related to the first account, to accept thefirst account for making the payment; and a payment module, responsiveto the approval module to map the first account to a second accountmaintained by an online payment service and to activate software to makepayment for the transaction with funds in a second currency from thesecond account.
 3. The system of claim 2, wherein the second account isinternal to the online payment service and the first account is externalto the online payment service.
 4. The system of claim 2, wherein a thirdparty participates in the transaction.
 5. The system of claim 2, whereinthe at least one hardware processor is further configured to include arisk analysis module to evaluate the risk involved in accepting thefirst account for making the payment.
 6. The system of claim 5, whereinevaluating the risk involved is performed by a third party.
 7. Thesystem of claim 5, wherein evaluating the risk involved comprisesevaluating information accessible to a transaction facility.
 8. Thesystem of claim 2, wherein the information related to the first accountfor making the payment is transmitted from a mobile device.
 9. A systemcomprising: at least one hardware processor maintained to communicatewith a client machine via a network interface, the at least one hardwareprocessor configured to include: a receiver module to receive, via amessage exchange with the client machine, information that identifies afirst account for making a payment for a transaction in a firstcurrency, the information being generated by selection of a selectableelement at a user interface at the client machine, the message exchangeutilizing the network interface of the at least one hardware processor,the message being configured as a message in an application protocol andtransmitted by the client machine; a retriever module residing at anonline payment service to retrieve information related to the firstaccount; an approval module, responsive to risk analysis of theinformation related to the first account, to accept the first accountfor making the payment; and a payment module, residing at the onlinepayment service and responsive to the approval module, to map the firstaccount to a second account maintained by a payment service and toactivate software to make payment for the transaction with funds in asecond currency from the second account.
 10. The system of claim 9,wherein the second account is internal to the online payment service andthe first account is external to the online payment service.
 11. Thesystem of claim 9, wherein a third party participates in thetransaction.
 12. The system of claim 9, wherein the risk analysiscomprises evaluating the risk involved in accepting the first accountfor making the payment.
 13. The system of claim 12, wherein evaluatingthe risk involved comprises evaluating information accessible to atransaction facility.
 14. The system of claim 12, wherein evaluating therisk involved is performed by a third party.
 15. The system of claim 9,wherein the information related to the first account for making thepayment is transmitted from a mobile device.
 16. A system comprising: atleast one hardware processor maintained to communicate with a clientmachine via a network interface, the at least one hardware processorconfigured to include: a receiver module to receive, via a messageexchange with the client machine, information that identifies a firstaccount for making a payment for a transaction in a first currency, theinformation being generated by selection of a selectable element at auser interface at the client machine, the message exchange utilizing thenetwork interface of the at least one hardware processor, the messagebeing configured using a communication protocol specified in anapplication layer and transmitted in a transport layer by the clientmachine; a retriever module to configure a request to retrieve, from anexternal server over a communication network, information related to thefirst account, and to retrieve the information pursuant to the request;an approval module, responsive to risk analysis of the informationrelated to the first account, to issue a request to accept the firstaccount for making the payment; and a payment module, responsive to theapproval module, to map the first account to a second account maintainedby a payment service and to activate software to make payment for thetransaction with funds in a second currency from the second account. 17.The system of claim 16, wherein the second account is internal to thepayment service and the first account is external to the paymentservice.
 18. The system of claim 17, wherein a third party participatesin the transaction.
 19. The system of claim 16, wherein the at least onehardware processor is further configured to include a risk analysismodule to evaluate the risk involved in accepting the first account formaking the payment.
 20. The system of claim 19, wherein evaluating therisk involved comprises evaluating information accessible to atransaction facility.
 21. The system of claim 16, wherein theinformation related to the first account for making the payment istransmitted from a mobile device.